\section{Introduction}
\label{sec_introduction}
%Security is an important issue 
Organizations, such as hospitals and financial institutions, have to ensure compliance with regulatory, industry and internal mandates. The Health Insurance Portability and Accountability Act  (HIPAA) \cite{USCongress1999} for health care organizations and the Gramm–Leach–Bliley Act (GLBA) for the financial services industry are examples of these regulations. Noncompliance can incur important financial and reputation losses, e.g. a financial institution can be fined up to \$100,000 for each violation of GLBA~\cite{LAWYERS.COM}. 

%Why MDE
Model Driven Engineering (MDE) is currently one of the most promising approaches to secure IT systems and infrastructures since it allows formal system analysis and the production of IT infrastructures that are secure-by-design.
% Challenges to MDS
The specialization of MDE to security, called Model Driven Security (MDS), however faces  challenges. One major challenge is developing models that are simple but, at the same time, expressive enough to correctly capture requirements found in regulatory and internal mandates such as privacy obligations \cite{Ni2008,Mont2004a} and usage controls \cite{Park2004}. This lack in the expressiveness of current MDS security models has been recognized in \cite{Basin2011} where the authors recognize that ``{\it many systems have security requirements that go beyond access control, for example, obligations on how data must or must not be used once access is granted}''.
Indeed, most current MDS approaches only consider access control requirements \cite{Lodderstedt2002,Mouelhi2008,Morin2010a,Basin2011}, and therefore they do not cover, for example, HIPAA and GLBA regulations which often correspond to obligation requirements \cite{Ni2008}, e.g. an obligation to send customers a notice every year for as long as the customer relationship lasts or an obligation to notify a patient upon the disclosure of his personal health information to a third party. 

Another MDS challenge is update of security requirements at runtime. In most current MDS approaches, security is integrated with the business logic at compile time, making impossible to adapt resulting systems with new regulations. Furthermore, current approaches do not provide means to monitor security violations. Consequently, violations can not be dealt with.% by, for example, activation of new security rules to compensate detected policy violations. %Keeping a clear traceability between the security model and its IT enforcement is another important factor that must be considered to ensure that requirements are correctly enforced by the infrastructure.

In this paper, we propose an MDS approach fulfilling the aforementioned requirements. More specifically, we introduce a security Domain Specific modeling Language (DSL) to support expression of fine-grained advanced security policies. Our DSL includes both obligations and authorizations (access control) requirements and, therefore, many practical requirements are covered. The DSL also allows the specification of reaction policies, i.e. how obligation violation should be compensated. In the DSL, security policies are specified on an abstract level to enable policy reuse in different systems, To bind a policy to a given system, mapping rules are defined to link the abstract policy entity to their more concrete counterparts in the target system. Currently, we focus on securing Java applications, however the concepts underlying our approach could well be used with other object-oriented languages, with slight adaptations. 


To enforce security policies specified in our DSL, we propose an architecture that combines the paradigm of Policy Enforcement Point (PEP) / Policy Decision Point (PDP) with Aspect-Oriented Programming (AOP). More precisely, we define a set of generic AOP aspects to monitor the target application. This set of monitors (the PEPs in our architecture) monitor change in the target application and notify the PDP of changes that are relevant to the security policy. The PDP on the other hand is a prolog engine implementing the semantics of our security policies and is responsible for taking access control decisions and monitoring obligation fulfillment and violation. The PDP may also update the effective security policy after the detection of security violations, e.g. violation of an obligation could lead to an update of the effective access control policy. One main advantage of our approach is its generic character since it can easily be used to secure any Java-based application by simply integrating the application within our framework.

%Furthermore, given a security model, we automatically generate security components necessary to enforce the policy in the target system. Security components provide monitoring capabilities, enabling the enforcement of reaction policies upon detection of security violations, in addition to enforcement and management of access control and obligation policies.

%The architecture generated to enforce security requirements complies with the Policy Enforcement Point (PEP) - Policy Decision Point (PDP) architecture allowing policy update at runtime if necessary. To ensure the traceability between security requirements in the policy and the target application, security policy concepts are explicitly mapped to their corresponding concepts in the application using the DSL. Moreover, policy violations are monitored and it is possible to define reaction policies to deal with violations when they occur.

%Paper outline
The remainder of the paper is organized as follows. Section \ref{sec:motivation-approach} discusses some of the challenges \textsc{Mds} is currently facing on a small running example. Section \ref{sec:ApproachOverview} presents an overview of our approach. Section \ref{sec:DSL} describes \SAR (a shortcut for \emph{Security@Runtime}), our \textsc{Dsl} proposal for dealing with the identified challenges, and gives a general idea on the \textsc{Dsl} semantics. Section \ref{sec:Validation} shows performance results of our tool prototype for two real-life systems. Section \ref{sec:RW} contrasts \SAR with other contributions; and Section \ref{sec:Conclusion} concludes with some perspectives and future work.

\begin{figure*}[t]
	\center
	\resizebox{\textwidth}{!}{\includegraphics{MedicalSystem.png}}	
	\caption{The Medical System (\textsc{Ms}).}
	\label{fig:example-code}
\end{figure*}
